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I. 



INTRODUCTION 



Over the last three decades, the sheer number of computer and communications 
systems in the Department of Defense (DoD) has increased dramatically. Much of the 
increase is directly attributable to the rapid rate of technological change and growth of 
computing capabilities since the early 1960s. Unfortunately, over these nearly thirty 
years, the acquisition of computer hardware and software systems within DoD has been 
plagued by long developmental and implementation time periods often leading to 
situations where a computer system is technologically years out-of-date before ever being 
fielded. In addition to significant schedule delays, cost overruns have become the norm. 
In the DoD, it is common for software development costs to exceed initial budget 
estimates by 50-100% [Ref. 1]. Of even greater concern, many of the fielded systems 
were “stove-pipe” systems — systems which performed a specific set of tasks well but 
were incapable of operating and communicating with other computer/communication 
systems. 

Ideally, a computer system should perform a multitude of user tasks and be able to 
operate harmoniously with other systems. Computer users should not require multiple 
computer systems to perform their jobs, yet this is just the road DoD was traveling the 
last thirty years particularly with regards to tactical computer systems. DoD, to their 
credit, has been struggling with and resolving many of these issues. The Global 
Command and Control System (GCCS) is an excellent example. GCCS incorporated the 
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functionality of many command and control (C2) software systems and packaged them 
under one major software system. Information Technology for the 21 sl Century (IT-21) is 
an “...effort to fundamentally transform the way the Department of the Navy (DON) 
plans and budgets for information technology (IT) acquisition - shifting from acquiring 
IT as a centralized, large-scale system to considering IT as a disposable commodity” 
[Ref. 2]. IT-21 initiatives provide a good foundation for the concept of a single platform, 
single operating system environment for all DoD systems. Moreover, IT-21 has also 
gone so far as to state that Microsoft Windows would be the standard operating system 
for all systems. IT-21 espouses many common sense philosophies but DoD has a long 
way to go to implement these visions most notably in the realm of tactical computer 
systems. 

Given the rapid rate of today’s technological changes and in an environment of 
austere budgets, DoD faces a significant challenge relating to hardware and software. 
Recent technology advances have allowed for the relatively simple and rapid 
development of software applications. At the same time, the capabilities and demand for 
computer networks has dramatically increased. At a time when network technologies are 
maturing and mobile computers (i.e., laptops with network access) are becoming 
commonplace, major tactical computer systems (programs that began prior to this 
developmental age) are just now being fielded. Once again, long developmental and 
acquisition processes have led to the fielding of technologically antiquated and stove-pipe 
style systems. In an era where mobile computing is commonplace, the need for 
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applications to reside on one light weight, portable computer running one operating 
system is paramount. 

Rapid Application Development (RAD) is quickly becoming the favored process 
for Win32 software development throughout many industries. RAD is especially 
meaningful to a DoD Command, Control, Communications, and Computers and 
Intelligence (C4I) community continually confronted and challenged by Moore’s Law 
(which states that the number of transistors on a computer chip will double every 18 
months at the same cost) [Ref. 3]. Unless DoD begins to accept and practice some form 
of rapid application development techniques they will never get ahead of the technology 
beast. 

The use of wireless Local Area Networks (WLANs) in the commercial industry 
has blossomed in the past few years and the recent strides in protocol standardization and 
advancing capabilities of wireless equipment have opened up new possibilities of how 
data communications can be accomplished. There is a need for the Marine Corps to 
evaluate this technology as an network architecture to add robustness and increased data 
throughput over and above the current capabilities of the combat net radio (CNR) on the 
battlefield. 

A. OBJECTIVE 

The objective of this thesis is to demonstrate that wireless COTS technologies and 
COTS software development tools can be used to quickly enhance the ability of today’s 
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warfighters to accomplish their mission, and should become the accepted practice within 
the DoD, when feasible, not the exception. Specifically, this thesis seeks to demonstrate 
the use of COTS software developmental tools to “rapidly” create a Win32 fire support 
planning application. Additionally, this thesis seeks to demonstrate the need and 
practical application of implementing the use of WLANs at the Marine Corps regiment 
level and below for tactical communications. 

B. RESEARCH QUESTIONS 

This research addresses the following primary research questions: 

1 . Can a Commercial Off The Shelf (COTS) wireless technology architecture be 
implemented to increase the bandwidth to allow timely passing of data 
intensive information at the Marine regiment level and below? 

2. Can COTS software developmental tools be used to produce software 
applications to aid the warfighter? 

C. METHODOLOGY 

The research methodology consisted of a literature survey of both government 
C4I publications and commercial industry documents, personal interviews with 
commercial industry representatives and military stakeholders, and field testing of both 
the developed software and COTS wireless equipment. 
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1 . 



Literature Review 



A literature survey was conducted to get background material concerning Marine 
Corps communications equipment, commercial wireless equipment, wireless 
communications standards, both military and industrial, as well as current and planned 
command and control systems/platforms. 

2. Interviews 

Personal, telephone, and E-mail interviews/discussions were conducted with 
individuals who work in the commercial wireless industry, as well as Navy and Marine 
Corps representatives involved in mobile computing/communications at U.S. Navy Space 
and Naval Warfare Systems Center (SPAWAR), Marine Corps Tactical Systems Support 
Activity (MCTSSA) and the Marine Corps Warfighting Lab (MCWL). Without their 
input, support, and generous cooperation this research could not have been completed. 

3. Field testing 

Field testing of the Fire Support Planning System (FSPS) program and wireless 
equipment was conducted at Camp Pendleton, CA with the support of Marines from the 
artillery community and MCTSSA. The purpose of the field testing was to get feedback 
from the end user on the functionality, usability, and responsiveness of the FSPS program 
and wireless equipment. 
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D. ORGANIZATION 



This thesis is divided into six chapters which are organized as follows: 

Chapter II provides an introduction to Rapid Application Development (RAD) 
and in-depth section on commercial wireless technologies available today. 

Chapter III provides an overview of the Marine Corps fire support and command 
and control systems, addressing its hardware, software, communications architecture, and 
capabilities in its current state as well as the Marine Corps’ proposed future state. 

Chapter IV provides information on the fire support planning process, and a 
detailed examination of the development of our Fire Support Planning System (FSPS) 
application including concept, development, and framework. 

Chapter V explores our testing methodology of the FSPS application transmitted 
over the current C2 architecture as well as commercial wireless equipment. Additionally, 
our approach to gathering user feedback on the FSPS application will be addressed. 

Chapter VI discusses the results of the field testing and user feedback of the FSPS 
program. 

Chapter VII contains the conclusions and recommendations of this thesis and 
describes some of the further research opportunities in this area of study. 

E. EXPECTED CONTRIBUTIONS OF THIS THESIS 

The major contribution of this thesis is the study of COTS development tools to 
provide a basic conceptual framework for the development of Win32 compliant 
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applications capable of interacting with the “Command and Control PC” (C2PC) software 
program. Specifically, the Fire Support Planning System (FSPS) program, a proof-of- 
concept application, as version 1.0, can then be used as the basis for future fire support 
application development. Additionally, the study of current wireless technologies and 
how the use of these technologies could enhance the capabilities of the Marine Corps 
tactical communications architecture to transmit the Win32 compliant applications is a 
benefit of this thesis. 
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II. CORE TECHNOLOGIES BACKGROUND 



This chapter will provide basic background information and definitions covering 
rapid application development and commercial wireless technologies. 

A. RAPID APPLICATION DEVELOPMENT (RAD) 

The development of any software application, be it military or civilian, is a time 
consuming and highly laborious process. Database Management Systems (DBMS) and 
4 th generation programming languages were supposed to be the savior of the development 
manager [Ref. 4]. This has not been the case. In the more recent past, rapidly improving 
hardware platforms and microprocessors, decreasing military budgets, DoD acquisition 
reform, the Navy’s Information Technology for the 21 st century (IT-21) initiatives, and 
the resulting change in military doctrine have dramatically affected the types of 
applications the military requires and the methods DoD uses to develop and acquire 
software. These influences place tremendous pressure on software developers to get 
quality applications into the field faster and cheaper than ever before. 

The traditional Software Development Life Cycle (SDLC) is a sequential, step-at-a- 
time approach to application development. SDLC has several phases; determining 
requirements, systems analysis and design, building, testing, implementing, and 
maintenance. RAD is a software development methodology which is intended to provide 
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a higher quality application at a much faster development rate than the traditional 
approach [Ref. 5]. 

The RAD methodology is designed to take advantage of off-the-shelf software 
development design tools. Development tools such as Microsoft’s Visual Basic and 
Visual C++ allow developers to add new functionality to individual stand-alone systems 
or to bring together systems which are currently independent of each other with a 
common Graphical User Interface [Ref. 6]. Hence, these applications are often referred 
to as “gluing languages.” 

The RAD methodology provides a means for more accurately capturing user 
requirements than SDLC. RAD utilizes interviews and user workshops to capture 
requirements; evolutionary prototypes are then developed in an iterative process which 
includes refining data models, process models, and object models [Ref. 7]. RAD uses 
tools that support “visual” development, creation of fake prototypes (pure simulation), 
creation of working prototypes, multiple languages, use of reusable components, use of 
standard APIs, and version control [Ref. 8]. 

In essence, RAD is a more cyclical and evolutionary process than the SDLC method. 
RAD seeks to leverage current software development tools and Computer Aided 
Software Engineering (CASE) tools coupled with close contact and involvement from the 
end users to rapidly develop and field software applications. The RAD methodology 
seeks the “80% solution” today in lieu of the perfect solution too far into the future to be 
of any real value. 
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Within the DoD, software development practices traditionally followed the SDLC 
approach. Moreover, the approach was governed by military standards (MilStd). The 
most notable MilStd for software development was MilStd-498, Software Development 
and Documentation (dated 5 December 1994). MilStd-498 recognized three software 
development strategies: The Waterfall Method, The Incremental Method, and The 
Evolutionary Method. All three methods have their own particular strengths and 
weaknesses (a discussion of which is beyond the scope of this thesis). However, these 
established methodologies are all versions of the traditional SDLC. Though the methods 
delineated in MilStd-498 were not mandatory DoD requirements, the standard was state- 
of-the-art and accepted and used by much of the commercial software development 
industry. On 27 May 1998, DoD cancelled MilStd-498 in lieu of the IEEE 12207 
standard. 

B. WIRELESS TECHNOLOGY 

The purpose of this section is to provide the reader with a broad overview of the 
commercial wireless technologies available today that the Marine Corps could possibly 
take advantage of to solve its communication problems at the regiment level and below. 
The focus of the section will be on wireless local area networks (WLANs), their 
characteristics and their capabilities. 
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1 . 



Wireless LAN 



A WLAN allows workstations to communicate with either a wired network or 
completely autonomous wireless network, while providing a user the ability to transmit 
and receive data in excess of 1 Mbps. A WLAN uses electromagnetic waves as the 
access medium, providing the user mobility and freedom from a wired LAN [Ref. 9]. 

2. Military Applications 

The military is focused on getting a true common tactical picture (CTP) of the 
battlefield. Realizing this goal will require the passing of near real-time data both to and 
from the lowest organizational levels. The Marine Corps has the adequate bandwidth 
required to pass data-intensive information down to the regimental level. The problem 
with the Marine Corps communications architecture is that it does not provide the needed 
amount of bandwidth below the regimental level. The current architecture, i.e., 
S INC GARS, while able to pass data, does so at a very’ slow rate of throughput that is not 
adequate for future applications. A WLAN approach at the regiment level and below 
could possibly solve this growing problem. 

3. Benefits of a Wireless LAN 
a. Mobility 

The Marine Corps is a highly mobile fighting force that must be able to 
communicate with its units while stationary or on the move. A WLAN can provide access 
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to real-time information to those units/individuals who cannot be hard-wired to a 



network. 



b. Installation Speed and Simplicity 

Marine units cannot afford to spend the time, nor is it operationally 
feasible, to lay networking cable while in the field. Installing a WLAN can be quick and 
easy and allow the Marine Corps the flexibility of taking the network wherever they go. 

c. Scalability 

WLANs are very resilient in that they can be built from small workgroup- 
like networks to full scale internets tied into a wired infrastructure network. Since 
Marine Corps units are hierarchical in nature and varying in size, WLANs are perfect for 
matching a topology to the application. 

4. How Wireless LANS Work 

a. Spread Spectrum 

The term spread spectrum (SS) describes a modulation technique which 
makes the sacrifice of bandwidth in order to gain signal-to-noise performance. Basically, 
the SS system is a system in which the transmitted signal is spread over a frequency 
much wider than the minimum bandwidth required to send the signal. The fundamental 
premise is that, in channels with narrowband noise, increasing the transmitted signal 
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bandwidth results in an increased probability that the received information will be 
correct. 

Spread spectrum uses wide band, noise-like signals. Because spread 
spectrum signals are noise-like, they are hard to detect. Spread spectrum signals are also 
hard to intercept or demodulate. Further, spread spectrum signals are harder to jam 
(interfere with) than narrowband signals. These Low Probability of Intercept (LPI) and 
anti-jam (AJ) features are why the military has used spread spectrum for so many years. 
Spread spectrum signals are intentionally made to be of a much wider band than the 
information they are carrying to make them more noise-like. 

Spread spectrum signals use fast codes that run many times the 
information bandwidth or data rate. These special spreading codes are called “Pseudo 
Random” or “Pseudo Noise” codes. They are called “Pseudo” because they are not real 
Gaussian noise. 

Spread spectrum transmitters use similar transmit power levels to 
narrowband transmitters. Because spread spectrum signals are so wide, they transmit at a 
much lower spectral power density, measured in Watts per Hertz, than narrowband 
transmitters. This lower transmitted power density characteristic gives spread spectrum a 
big plus. Spread and narrow band signals can occupy the same band, with little or no 
interference. This capability is the main reason for all the interest in spread spectrum 
today. The actual signal spreading available in commercial WLAN products is achieved 
with one of two techniques: frequency hopping or direct sequence [Ref. 10]. Currently, a 
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WLAN implementing frequency hopping cannot talk to a WLAN implementing direct 
sequence, and vice versa, due to the different modulating schemes. 

(1) Frequency Hopping Spread Spectrum (FHSS) Technology. 
Frequency hopping is a method of transmission that uses many narrowband channels 
(multiple frequencies) to transfer the information. The center frequency is shifted, or it 
“hops,” by a pseudo random code synthesizer in the transmitter. Varying the 
instantaneous frequency results in an output spectrum that is effectively spread over the 
whole range of frequencies that are generated. Both the transmitter and receiver must 
have the same system timing so that they are both hopping to the next frequency at the 
same time [Ref. 1 1]. Frequency hopping is depicted in Figure 1. 

» Power 




Figure 1. An Example of Frequency Hopping Spread Spectrum Signal From Ref. [17]. 

(2) Direct Sequence Spread Spectrum (DSSS) Technology. 
Direct sequence is a method of transmission where the carrier signal is multiplied by a 
pseudo-noise (PN) digital signal that spreads the information over a wide frequency band. 
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The resulting signal looks like a noise signal in the frequency domain, making it hard for 
anyone to detect the signal. The receiver must be using the same PN signal, which is then 
multiplied to the received signal to detect the original transmitted information[Ref. 1 1]. 

(3) FHSS vs. DSSS. FHSS poses several advantages over 
DSSS technology. It has inherent immunity to narrowband interference even though it 
operates in an unlicensed band. It also provides greater scalability features than DSSS. 
A disadvantage to FHSS technology is its inability for higher speed throughput in the 2.4 
GHz band. With the IEEE 802.1 la extension slated for ratification in 2001, products in 
the 5 GHz range will be available from leading frequency hopping wireless vendors. 
With 5 GHz-based radios, these manufacturers will be able to offer solutions in excess of 
20 Mbps. Additionally, FHSS systems have lower power consumption than DSSS. To 
attain comparable interference and multipath immunity, a direct sequence system draws 
greater power than a frequency hopping system. Furthermore, FHSS products are 
designed to go through various power management tiers ranging from transmit/receive to 
doze and sleep during a time interval defined by the access point (base station) [Ref. 27]. 

b. Protocols 

A protocol is “a formal description of a set of rules and conventions that 
govern how devices on a network exchange information [Ref. 12].” WLANs are a 
relatively new technology. Development and support of industry standards (protocols) 
increases the adoption of technology. Standardization of the WLAN industry will 
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promote the use of WLAN technologies due to greater customer acceptance. This allows 
customers the ability to solve more of their business problems with WLAN solutions as 
well as adapting systems that allow freedom of choice from vendors. In the commercial 
WLAN industry the most recent standard developed is the Institute of Electrical and 
Electronics Engineers (IEEE) 802.1 1 standard of 1997. 

The IEEE 802.1 1 standard is a breakthrough for the wireless industry. The 
IEEE is an internationally recognized standards setting body. By setting a standard, 
vendors will work to develop equipment that meets that standard allowing 
interoperability with other vendors equipment. The focus is on the radios and networks 
operating in the 2.4 GHz Industrial, Science, and Medical (ISM) frequency band. The 
standard specifies the workings of the lower two layers, the Physical layer and the Data 
Link layer (sometimes called Media Access Control (MAC) layer), of the International 
Standards Organization (ISO) Open Systems Interconnection (OSI) seven-layer reference 
model. The OSI seven layer reference model is depicted in Figure 2. 
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Figure 2. The OSI Seven-Layer Model. 

“The Physical Layer in any network defines the modulation and signaling 
characteristics for the transmission of data” [Ref. 13]. IEEE 802.11 requires the use of 
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either of the two modulation techniques discussed earlier for radio frequency (RF) in the 
2.4 - 2.4835 GHz frequency band. FHSS with a data rate of 1 Mbps, or DSSS with a 
data rate of 1 Mbps and 2 Mbps. Each type of modulation schemes has its own unique 
advantages and disadvantages depending on the type and topology of network, and 
physical placement of the network (indoor or outdoor). 

“The MAC layer is a set of protocols which is responsible for maintaining 
order in the use of a shared medium” [Ref. 14]. At the MAC layer, the 802.1 1 protocol 
uses a process called Carrier Sense Multiple Access with Collision Avoidance 
(CSMA/CA). This protocol is similar to the CSMA/CD (collision detection) protocol 
that is used in wired ethemet networks. CSMA/CD is a communications protocol in 
which nodes contend for a shared communications channel, and all nodes have equal 
access to the network. Simultaneous transmissions (which will result in a collision) 
results in a random restart of those transmissions. CSMA/CA attempts to avoid these 
collisions before they occur due to their high cost in a wireless environment [Ref. 14]. 

Collision avoidance is used in wireless networks because a node that is 
transmitting cannot “hear” another node transmitting due to its own signal drowning out 
any incoming signal” [Ref. 13]. With collision avoidance, a node wanting to send a 
message, once it determines the channel is clear, will transmit a request to send (RTS) 
packet that includes the duration of the message to the destination node. 
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The duration of the message is known as the network allocation vector 
(NAV). Once the destination node receives the RTS packet, it will return a clear to send 
(CTS) packet to the originating node, along with the NAV notifying all other nodes to be 
quite on that channel for that duration. The originating node then sends the data packet to 
the destination. The destination then runs a cyclical redundancy check (CRC) to ensure 
the packet was received intact. If so, the destination node sends the originating node an 
acknowledgement (ACK) packet. If during the transmission the CTS packet is not 
received, the originating node assumes a collision has taken place and starts the RTS 
process over again [Ref. 13]. This RTS, CTS, data, and ACK process helps alleviate 
what is called the “hidden node” problem as seen in Figure 3. 




As depicted, node A can communicate with node B, and node B can 
communicate with node C, but node A cannot communicate with node C. In this scenario, 
when node A “listens” on the channel and finds it clear, node A will send the RTS packet 
to node B. The fact is that node C may be transmitting to node B at that same time. 
Node B will not return a CTS packet to node A. 



19 




Security is another feature that IEEE 802.11 addresses at the MAC layer. 
Included in the standard is a form of encryption called the Wired Equivalent Privacy 
(WEP). WEP uses a 64-bit seed key and the RC4 algorithm, a widely used method of 
encrypting bit streams over an RF medium. While not as strong as the military 
communications security (COMSEC) algorithms, WEP should suffice for most civilian 
applications [Ref. 13]. 

Power management of wireless data communications devices is a very 
important issue for the mobile user, especially for the military. Batteries are not cheap, 
and recharging of the batteries is not always an option when deployed in the field 
environment. The 802.1 1 standard provides the ability at the MAC layer for the mobile 
wireless workstation to go into a “sleep mode,” or low power setting, for a certain time 
interval determined by the base station [Ref. 13]. 

The IEEE 802.11 standard has brought better interoperability within the 
commercial wireless industry, but there are several issues from a military aspect that the 
standard does not address. Low bandwidth and high bit error rate (BER) communication 
channels are common in the military, and in an attempt to address these specific issues, 
the Department of Defense (DoD) created MIL-STD-188-220A, or the military’s 
interoperability standard for digital message transfer device subsystems (DMTDs). This 
MIL- STD has been superceded by MIL-STD-188-220B. 

This military standard “addresses the communications protocols and 
procedures for the exchange of information among DMTDs, among C 4 I systems, and 
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between DMTDs and C 4 I systems participating in inter-Service and intra-Service tactical 
networks” [Ref. 15]. This standard concerns itself with the physical, data link, and 
network (internet) layers of the OSI reference model. It details mandatory system 
standards for using DMTDs in tactical digital communications systems. 

As stated earlier, IEEE 802.11 utilizes three signaling packets for each 
data packet; the request to send (RTS), the clear to send (CTS), and the acknowledgment 
(ACK) to maintain transmission reliability. This is in addition to the normal network 
protocol acknowledgments. According to Martin Nemzow, this scheme typically reduces 
"wireless channel performance" by at least 50% due to increased overhead of these 
signaling packets [Ref. 16]. 

The MIL-STD-188-220B protocol utilizes a "Type 1" acknowledgement 
or unacknowledgement to provide a much more flexible degree of flow control. 
Therefore, bandwidth utilization can be dramatically improved under optimal channel 
conditions. 

The MIL-STD-188-220B supports transmissions in a half-duplex mode 
over radio, wire-line, and satellite links; point-to-point, multi-point, relay or broadcast 
connectivity between stations; and forward error control (FEC) for maintaining data 
integrity over the link. FEC is critical to the success of the protocol over low bandwidth, 
high BER wireless channels. The IEEE 802.11 standard does not support FEC. Aside 
from the limited bandwidth and high BER already mentioned, wireless networks have 
high latencies and temporary disconnects that must be dealt with by network protocols 
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and applications. One of the major drawbacks of using the standard (wired) transmission 
control protocol (TCP) to address these issues is that TCP assumes all packet losses over 
a network are due to network congestion. To alleviate this problem, TCP drops its 
transmission windows size before retransmitting packets resulting in an unnecessary 
reduction in the utilization of channel bandwidth. This also results in yielding poor 
throughput and very high latencies. Using FEC with wireless networks can resolve some 
of the bit errors before they can become a serious problem. [Ref. 15] 

MIL-STD-188-220B uses the Extended Golay (24, 12, 8) coding 
algorithm as its method for forward error control. This allows the receiver to detect and 
automatically correct errors in a received block of information. When used in 
conjunction with the optional Robust Communication Protocol (RCP), it provides the 
additional processing to aid the transfer of up to 67,200 data symbols in a single 
transmission with better than a 90% probability of success. 

An interesting feature of the MIL-STD-188-220B protocol is the 
incorporation of military communications security (COMSEC) into the very lowest layer 
within the protocol data unit (PDU). There are three ways of applying COMSEC to 
PDUs: the transmission frame structure includes either a COMSEC preamble and 
postamble wrapped around a synchronization component and the data field; an embedded 
COMSEC message indicator into the synchronization component (without a preamble, 
but with a postamble); or provides no COMSEC whatsoever (neither preamble nor 
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postamble). The preamble and postamble are only used when link encryption is used 
[Ref. 15]. 

Appendix H in the MIL-STD-188-220B provides a procedure for active 
intranet topology updates. The "intranet" is defined as all the processors and CNRs 
within a single transmission channel. Within the network, individual nodes know nothing 
about neighbor nodes that are more than one hop away. Therefore, they need to 
continually exchange network connectivity information as the physical topology changes 
in the form of a topology update packet. All topology update packets are transmitted 
exclusively using a global multicast address whenever a particular node detects either a 
failed link, a new link, or a change in the quality of the link (if link costs are used). 
Sparse spanning trees are used vice full spanning trees to build topology tables to avoid 
the overhead of full spanning trees [Ref. 15]. 

When nodes in an intranet need to communicate, but are not close enough 
to their neighbors to transmit or receive, intranet relaying is required to be capable of 
hearing each other's radio transmissions. The MIL-STD-188-220B protocol provides a 
procedure for relaying packets across a CNR intranet using very efficient source-directed 
routes. Source directed routing provides a simple non-dynamic procedure for relaying a 
packet from an originator to one or more destinations. The source calculates the path 
through the network to reach each destination, and this route is encoded into the intranet 
header. Paths along a source directed route are expected to never have common nodes 
[Ref. 15]. 
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On a multiple-subscriber-access communications network, MIL-STD-188- 
220B also provides for a mandatory net access control (NAC) algorithm which is used to 
detect the presence of active transmissions. It also provides a means to preclude data 
transmissions from conflicting on the network [Ref. 15]. 

c. Components 

(1) Wireless LAN Adapters. Wireless LAN adapters allow end 
users to access the WLAN. These adapters may be implemented in the form of PC Cards, 
formerly known as Personal Computer Memory Card International Association 
(PCMCIA) cards, in notebook or palmtop computers, as PCI or ISA cards internally in a 
desktop computer, or can be devices that are fully integrated into handheld entry devices. 
An antenna is built into the structure of the PC card so that the computer can 
communicate on the WLAN. An example of a PC card can be see in Figure 4. 




(2) Access Point. An access point (AP) connects the wireless 
network to a wired network utilizing a standard ethemet cable. It is a 
transmitter/receiver, or transceiver, that all wireless devices communicate with to transmit 
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and receive data to other wireless devices in the WLAN or to the wired network itself. 



The access point, if it has a detachable antenna, is usually mounted high so that a greater 
radio coverage is obtained, and located in a spot that is the most feasible for all mobile 
users to be able to communicate with it. An example of an access point can be seen in 
Figure 5. 




Figure 5. An Example of an Access Point. 

An access point is not required for mobile computers to 
communicate with each other on a totally wireless LAN. A configuration of this type is 
called an independent or peer-to-peer WLAN. Most WLANs will utilize an access point 
to extend the network and provide movement for its mobile clients while still allowing 
them access to the wired network. A typical WLAN configuration is depicted in Figure 6. 
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5. Employment Considerations 



a. Range/Coverage 

The coverage (range) obtained by the mobile clients depends on which 
vendors equipment is employed, which type of modulation is used, and the environment 
that the access point is placed in, either outdoor or indoor. Consideration must also be 
given to obstructions in the line-of-sight (LOS) between the mobile client and the access 
point that can degrade the range. Range can be extended through the use of microcells 
where the user can roam from microcell to microcell whose coverage overlaps. 
Overlapping cells is depicted in Figure 7. 
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Figure 7. Overlapping Cells After Ref [22], 



b. Throughput 

Throughput in a wireless LAN is similar to that of a wired LAN in that it 
is dependent on the type product installed and the configuration utilized. Other factors 
that affect throughput in a WLAN are the number of users on a particular channel 
(congestion), possible bottlenecks at the wired-to-wireless interface (access point), 
bottlenecks in the wired network itself, range, and multipath interference. The throughput 
claimed by most vendors range from 1 Mbps up to 10 Mbps. 

c. Integrity and Reliability 

Wireless communications have been in use for many years in both the 
military and commercial industry. The WLAN industry is a growing field that has 
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developed, and continue to develop robust technologies that provide both integrity and 
reliability for data communications to a level comparable to a wired LAN. 

d. Interoperability with Wired Infrastructure 

In order for a WLAN to be truly successful, they must interoperate 
seamlessly with the wired LAN infrastructure. One of the goals in data communications 
networks is to make all the background work that the network does transparent to the 
user. Great strides have occurred, through the institution of industry standards, in making 
the WLAN “user friendly” so that user will trust that it will work. The majority of 
WLAN systems today support industry standard interconnection protocols like the IEEE 
802.3 (Ethernet) and IEEE 802.5 (Token Ring). Commercial vendors are adding support 
for wireless clients through the use of software drivers that come with their network 
operating system (NOS) so that setup and configuration are relatively easy. The result is 
that a wireless client looks just like any wired client to a network. 

e. Interoperability with Wireless Infrastructure 

As stated earlier, vendor products using the same modulation scheme, 
either FHSS or DSSS, can communicate with one another if they are implemented in the 
same way. One of the goals of the IEEE 802.11 standard is to increase this 
interoperability between vendors so that a consumer can choose which product to 
purchase based on capability, while ensuring that the equipment they buy will 
communicate with other WLAN systems. For example, a consumer could purchase an 
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access point from one vendor and purchase PC cards from another vendor with the 
assurance that they will communicate properly. 

f Interference and Coexistence 

WLANs operate in the unlicensed 2.4 GHz Industrial, Science, and 
Medical (ISM) frequency band. “Unlicensed” implies that other products may transmit 
on these same frequencies which could cause some interference to a WLAN. One of the 
products that operate in this band is a microwave oven, but most WLAN vendors account 
for this interference in the design of their products. Another concern is that of multiple 
WLANs coexisting in the same area. Depending on the vendor specific equipment being 
employed by the multiple WLANs, interference could exist. With the development of the 
IEEE 802.11 standard, and all vendors working toward that standard, the coexistence 
interference problem should decrease. 

g. Simplicity/Ease of Use 

The ease of use of a WLAN from a mobile client’s view has already been 
stated, but the simplicity and ease of use for a network administrator should not be 
overlooked, especially for the deployed military. Since it is truly “wireless,” there are no 
cables to pull as in a wired infrastructure except to the access point. The mobile clients 
and access points can all be configured and/or troubleshot prior to deployment to ensure 
they can communicate. In a rapidly moving environment like that of an infantry unit, this 



29 



time savings can be crucial while allowing the seamless passing of information while on 
the move. 



It. Security 

Security is of paramount importance in military communications. Because 
wireless communications has been so widely used within the military, the issue of 
security has been a design criterion for wireless equipment for quite a while. While the 
modulation schemes and encryption algorithms built into WLAN equipment do well to 
support must commercial applications, the military requires a higher level of 
communications security than is provided by most commercial vendors. 

As stated earlier, the MIL-STD-188-220B has the capability of supporting 
military communications security equipment. What has yet to be accomplished is the 
marriage of the military’s need for communication security and the ease of use of 
commercially off the shelf (COTS) WLAN equipment. This could be accomplished by a 
vendor including support the 188-220B military standard, but convincing one vendor to 
support this standard would only raise more interoperability issues and tie the military to 
only that vendor’s products. The services need to think bigger than that. We need to 
work in concert with the standards making bodies to ensure that our needs are voiced so 
that a robust standard can be developed that addresses all the issues that we face in a 
deployed tactical environment. While this is an important topic that needs to be 
addressed, it is beyond the scope of this thesis. 



30 



L Cost 

The cost of the components of a WLAN vary by vendor and will probably 
decrease in price as WLANs become more popular. Infrastructure costs (access points) 
are the largest costs to consider along with any antenna enhancements. An access point 
ranges in price from $1,000 to $2,000. A cost savings over a wired LAN is the money 
saved on cabling. Also, the timed involved in installing the network must be considered 
toward man hours and overhead. WLAN adapters vary on the type of card. PC cards 
range from $300 to $1,000 at the time of this writing. 

j. Scalability 

WLANs can scale from a small network to a very large ones. The area of 
coverage can be increased by adding more access points to your wireless network. This 
ease of scalability would work well in the overall network scheme the military uses and 
could enhance the ability of operating in a joint environment. 

k. Battery Life for Mobile Platforms 

Battery life is a very important issue for the Marine Corps infantry units. 
Batteries are not cheap and budgets are tight. The life of the battery will depend on the 
amount of use of the mobile computer, the types of applications they run, and the type of 
protocols that are being used. There is a lot of academia research currently being done on 
enhancing battery life and creating energy efficient protocols for the mobile computer. 
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Rechargeable batteries are certainly an option, but power is required for the recharger 
which may not be available at the company level and below unless an AC/DC adapter can 
be configured for use with a High Mobility Multipurpose Wheeled Vehicle (HMMWV). 
Also, with the feasibility of someday every Marine carrying or wearing a mobile 
computer, the logistics of managing and distributing the rechargeable batteries must be 
considered. When one or two Marines in a fire team needs batteries, who will provide 
them? While this is also an important issue, it is beyond the scope of this thesis. 
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III. BACKGROUND FOR DEMONSTRATION APPLICATION 



This Chapter will provide basic background information and definitions regarding 
automated fire support systems, the current software and tactical communications 
architecture of a Marine infantry regiment, and the planned future Marine Corps 
communications architecture. 

A. AUTOMATED FIRE SUPPORT SYSTEMS OVERVIEW 

1. Brief History of Automated Fire Support Systems 

The fire support community (“artillery community”) was perhaps the first combat 
arm community to explore automated command and control systems. In 1963 the US 
Army launched its first effort toward automation with the fielding of the Ml 8 Field 
Artillery Digital Automatic Computer (FADAC). This computer provided battery-center 
to center-of-target technical solutions for artillery firing units. The FADAC computer 
system automated the technical solution for placing artillery rounds on a given target, but 
did not address tactical fire support planning details. At this time, only half of the fire 
support process was automated. The other half, fire support planning, still remained 
manual and required voice communications. In 1978, the Army began fielding Tactical 
Fire (TACFIRE), which automated the tactical fire control process. TACFIRE was a vast 
improvement for fire support automation tools in that it addressed tactical artillery issues. 
The artillery community now had computer systems for both technical and tactical fire 
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support requirements. TACFIRE though, was not without its own problems. The 
physical size of the system was the most pressing issue, as the system required a 5-ton 
truck for transportation. As technology developed in the 1980’s, the TACFIRE software 
application was subsequently ported into smaller computers. The resulting system was 
referred to as Lightweight TACFIRE and was fielded to the Army’s light divisions in a 
small desktop-like computer designated as the Battlefield Computer Terminal (BCT). 

Though advanced for its time, the TACFIRE application had a very convoluted 
and unfriendly user interface. To address these shortcomings, the Army began the 
Advanced Field Artillery Tactical Data System (AFATDS) program. With an urgent 
need for a better fire support computer system and recognizing that the AFATDS 
program was behind schedule, the Army sought an interim solution. In response, the 
Army began fielding the Initial Fire Support Automation System (IFSAS) in 1993. 

IFSAS was literally nothing more than the TACFIRE system software ported 
into a Lightweight Computer Unit (LCU) [Ref. 9]. The LCU was the first real attempt to 
place a tactical software application on a true “PC”. The LCU was a “hardened” 80486 
computer with communication ports for tactical combat radios (today, the LCU also 
incorporates the pentium processor). As a PC, the LCU could literally be loaded with a 
variety of software applications. The LCU was a huge improvement over the BCT. 
However, recognizing the limitations and convoluted user interface of IFSAS, this 
application was intended as only an interim solution for fire support automation prior to 
the fielding of AFATDS. 
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2. Current USMC Fire Support Automation Systems 



Because the U.S. Marine Corps artillery community is relatively small. Marine 
artillery has traditionally aligned itself with the U.S. Army artillery community for 
doctrine and training, and additionally for hardware/software program and system 
development. Though the Marine artillery community does not necessarily acquire all 
Army developed systems, the Marine Corps has yet to develop or field any systems 
created solely for the Corps. All Marine fire support systems were initially designed 
primarily for the Army. 

Today the Marine Corps artillery has “digitized” nearly the entire fire support 
process from planning to execution. Though the Corps’ fire support system has the 
capability to operate in a complete digital mode, voice communications and manual 
procedures are still used to a great degree, primarily because of user interface and digital 
communication difficulties. 

Because the types and names of fire support computer systems used since the late 
1980s has changed rapidly, and to avoid confusion, the Marine Corps uses a single 
acronym, MCFSS (Marine Corps Fire Support System), to encompass all fire support 
related computer systems. Today, two major systems comprise MCFSS: the Lightweight 
Computer Unit (LCU) and the DMS (Digital Messaging System, formally known as the 
DCT or Digital Communications Terminal). The LCU, as shown in Figure 8, supports 
two types of fire support software; IFSAS and the Battery Computer System (BCS). 
IFSAS is used at the artillery/infantry battalion level and above for tactical fire support 



35 



functions and BCS is used at the artillery battery level for technical gunnery 
computations. The DMS is the ‘"forward entry device” used by forward observers to 
input fire requests to either IFSAS or BCS. 




Figure 8. Lightweight Computer Unit (LCU). 



Both IFSAS and DMS have worked fairly well but have their drawbacks. First 
and foremost the IFSAS software program, as previously discussed, is essentially the 
dated TACFIRE software ported over to a smaller, “modem” computer. IFSAS software 
was not designed and built from the ground up, nor was it built to improve user interfaces 
or functionality but rather the software was recoded to fit into a 80486 processor. The 
IFSAS application therefore maintained TACFIRE’s original menu-driven style interface 
and did not take advantage of available and more user friendly windows style interfaces. 
Menu driven interfaces are not wrong, or even bad per se, but if poorly designed can be a 
chore for users to negotiate. 
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IFSAS fits into this poor design category. From the user point of view, the 
interface is extremely convoluted requiring extensive user experience. Menu items are 
all pneumonics which are often not intuitively named. Example pneumonics and their 
English translation are presented below in Table 1 . 



Pneumonic 


English Translation 


NNFP;RESFU 


Non Nuclear Fire Plan: Reserve Firing Unit 


ATI;TBMOD 


Artillery Target Intelligence; Target 
Buildup Report 


ATI;COMD 


Artillery Target Intelligence; Command 


SYS;PTM 


System; Plain Text Message 


FM;FOCMD 


Fire Mission; Forward Observer Command 



Table 1 . IFSAS Pneumonics. 



Because of this menu design, locating a desired input screen is often a tedious, hit 
or miss evolution. Users not intimately familiar with the system spend valuable time 
searching for required screens with the process outcome often resulting in tremendous 
user frustration. Moreover, once the desired input screen has been located, the user is 
presented with a very busy input form. 

Additionally, the IFSAS application supports only limited mapping functions. 
While map specific data is loaded into IFSAS, the data is used predominately by the 
application for computational purposes. The user is not presented with a really useful 
map display. The user is shown a gray screen with an outline of the input map. Included 
on the “map” are targets, firing units, fire support coordination measures, and other 
battlefield symbols. However, colors, contour lines, terrain features, and other items 
associated with a paper map are unavailable. While the user can see the relative location 
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of important battlefield symbols, he does not have a true digitized map with which he 
can interact. 

Another drawback of the LCU/IFSAS configuration is that only one application 
can be executed, namely IFSAS. While running the IFSAS application, it is not possible 
to switch to other applications such as a program within the Microsoft Office package 
thus greatly diminishing the inherent powers of a 80486 or Pentium processor. 

Another major drawback of the current MCFSS hardware/software systems is the 
lack of capabilities and functions provided to the forward observer (FO) by the DMS. 
This handheld entry device provides the FO with an ability to request fires, but provides 
no ability to input or view any aspect of the fire support plan. Nor does the user have a 
digital map. All map specific data must be collected from a traditional paper map. The 
DMS operates solely in the realm of fire support execution. 

B. CURRENT C2 ARCHITECTURE 

For the purpose of this thesis, we will be looking at the communications 
architecture at the infantry/artillery regiment and below. The primary means of 
communications at the infantry regiment and below is via the Single Channel Ground and 
Airborne Radio System (SINCGARS). Figure 9 depicts the notional communications 
architecture for the Marine infantry regiment and below. 
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Figure 9. Notional Communication Architecture. 



The SINCGARS radio works in either a single channel or frequency hopping 
mode. It is a Very High Frequency (VHF) Frequency Modulation (FM) radio that 
operates in the 30-88 MHz range providing operation on any of 2320 separate channels 
with a 25 KHz spacing between channels. Capabilities include voice, data, and remote 
control operations. Additionally, it has dataport compatibility with current terminal 
devices, network synchronization, and low probability of intercept/low probability of 
detection (LPI/LPD) via spread spectrum frequency hopping. 

The planning ranges for voice communications for the radios are 200 meters to 1 0 
kilometers for the manpack version (depending on power setting) and 10-35 kilometers 
(km) for the vehicular, power-amplified version. The throughput characteristics are 75 
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bps to 16 kbps, analog or digital. Communications security (COMSEC) is provided via a 
VINSON device. 

1. Data Transfer 

The planning ranges for data communications for the manpack radio are 600-4800 
bps at 3-5 km and 16,000 bps at 1-3 km at high power. For the vehicular version of 
SINCGARS, data rates of 600-2400 bps can be obtained at ranges from 5-25 km, 4800 
bps for 5-22 km, and 16,000 bps for 3-10 km utilizing the power amplifier. When 
planning for VHF communications, non-normal conditions such as rough terrain and bad 
weather must be considered as these factors will affect communication ranges. 

2. SIP 

The systems improvement program, or SIP, is an enhancement to the SINCGARS 
radio to increase data transmissions. Three primary improvements were added: a packet 
data mode for packet networks; a forward error correction (FEC) applique; and an 
updated channel access protocol that optimizes data throughput performance. 

3. INC 

The Internet Controller (INC) is a software controlled communications processor 
assembly, consisting of one circuit card assembly mounted with the SINCGARS 
Vehicular Amplifier/ Adapter assembly (VAA). The INC is part of the SINCGARS SIP 
program. It is a 4-port data router: 2 ports for operation with the SINCGARS SIP radios, 
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1 port for operation with a host computer, and 1 port for operation with either an 
Enhanced Position Location Reporting System Radio Set (EPLRS RS), a Tactical 
Multinet Gateway (TMG), or a second host computer. The INC can be thought of as a 
router on a card that provides interconnection between the SINCGARS SIP radio and an 
EPLRS Very High Speed Integrated Circuit (VHSIC). The sharing of information that 
will take place between the EPLRS VHSIC and the SINCGARS SIP once EPLRS is 
fielded is illustrated below in Figure 10. 




Figure 10. SINCGARS SIP and EPLRS Information Sharing From Ref. [21]. 



4. TCIM 



The tactical communications interface modem (TCIM) is actually a family of 



tactical modems provided by Litton Data Systems. The TCIM comes in three versions: an 



internal PC/AT card for IBM PC compatibles; an external hardened chassis modem that 



connects via a small computer system interface (SCSI) cable; and a standard Type II PC- 
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Card. The TCIM supports over 26 communications protocols including TCP/IP, MIL- 
STD-1 88-220, X.25, and TACFIRE Combat Net Radio (CNR). 

The TCIM interoperates with over 37 types of joint military tactical 
communications equipment. Of special interest to the Marine Corps is the SP-TCIM 
which is the removable Type II PC-Card with a capability throughput of 2 Mbps. Several 
Army units and the AFATDS program office have had success testing the SP-TCIM in a 
field environment. Additionally, MCTSSA has identified the SP-TCIM as a potential 
government off the shelf (GOTS) replacement for the two-channel modem of the rugged 
handheld computer (RHC) that is currently being development under the family of Data 
Automated Communication Terminal (DACT) umbrella. 

C. CURRENT INFORMATION SYSTEMS 

Technological advances have increased the number of computers in homes and in 
the workplace over the last few years. However, one workplace has remained relatively 
free of computers until recently. These workplaces are the command posts of the Marine 
artillery/infantry regiments and below. Until the last couple of years, the only computer 
systems to invade these spaces were those related with fire support (i.e., IFSAS). Today 
all of that has changed dramatically. 

The introduction of the Tactical Combat Operations (TCO) system. Intelligence 
Analysis System (IAS), Command and Control PC (C2PC) software application, and 
AFATDS has changed the face of the traditional infantry/artillery combat operation 
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center (COC) altogether. A discussion of these systems, both hardware and software, is 
important to understand the impact not only on the Marines using these systems, but also 
on the communications architecture they will ride on. 

1. Tactical Combat Operations (TCO) Program 

The TCO program was initiated to provide automation of maneuver command 
and control functions. The primary customer for TCO was the Marine infantryman who 
prior to the inception of TCO had no digital devices or computer C2 tactical systems at 
the regiment and below. TCO provides the warfighter’s a common tactical picture of the 
battlefield. Originally, TCO was designed to operate in a UNIX environment. However, 
during the acquisition process the program manager recognized that the intended users 
would not appreciate the UNIX user-interface nor would they be familiar with the 
operating system, so the decision was made to also include the Windows family of 
operating systems. Additionally, for many reasons beyond the scope of this thesis, the 
decision was also made to use the IBM Thinkpad©, a COTS product designated as the 
Intelligence Operations Workstation (IOW), as the hardware platform. Today, two 
versions of TCO exist. The UNIX based system and a Windows NT based system 
utilizing C2PC as the core software application. Now for perhaps the first time, a tactical 
system will operate in the same operating system environment as the familiar garrison 
systems. In reality, Marines spend the vast majority of their time in a garrison 
environment performing a variety of important tasks but not tasks necessarily associated 
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with their particular combat specialty. The time Marines have to become familiar with 
their tactical computer systems is actually somewhat limiting. It is therefore 
advantageous to have a tactical system which uses a familiar operating system. 

2. Intelligence Analysis Workstation (IAS) 

The IAS deploys as either a MEF IAS or as a single IAS laptop workstation. The 
MEF IAS serves as the hub of the Marine Air-Ground Intelligence System (MAGIS) 
which provides intelligence functionality to the echelon-tailored MAGTF all source 
intelligence fusion centers. At the regimental level and above the IAS suite consists of 
two HP UNIX based computers. At the battalion level the single IAS workstations are 
Microsoft Windows NT based systems now referred to as intelligence operations 
workstations (IOWs). The IOW meets the hardware requirements for both the IAS and 
TCO systems. 

3. C2PC, the Core C2 Software Application, Defined 

The “Command and Control PC” (C2PC) software program, a Windows based 
Command and Control (C2) system, began in 1994 as an internal research and 
development project of the Inter-National Research Institute (INRI). INRI’s concept was 
soon adopted by the Commanding Officer of the Marine Corps Tactical Systems Support 
Activity (MCTSSA). Today, the C2PC program is sponsored by both the Marine Corps 
and the U.S. Navy. Navy and Marine Corps versions of C2PC are still 
underdevelopment by both SPAWAR and MCTSSA respectively, however, as approved, 
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versions are actively being fielded to Marine, Navy, and Coast Guard units, as to all U.S. 
military units in Korea. 

The C2PC software application has tremendous potential to significantly increase 
the number of warfighters who can view a Common Tactical Picture (CTP) of the 
battlefield as provided by GCCS. C2PC is not a new command and control system, nor is 
it intended as a replacement for GCCS but rather it is an effective and efficient method of 
extending the availability and functionality of GCCS. Specifically, C2PC extends the 
JMCIS application portion of GCCS. The ultimate goal of the use of C2PC is to deliver 
not only a CTP, but also useful battlefield management tools, to as many warriors as 
possible. C2PC does this in a more efficient and cost-effective manner all while 
maintaining a simple yet robust graphical user interface of the Window’s family of 
operating systems. In essence, C2PC allows anyone, with the appropriate clearance, 
access to JMCIS, does so in the more user-friendly environment of Windows and, 
perhaps most importantly, requires only a relatively inexpensive Windows 95/98/NT/CE 
PC to operate, alleviating the need for expensive Unix terminals. Today, C2PC is the 
backbone software application for TCO. 

4. Advanced Field Artillery Tactical Data System (AFATDS) 

AFATDS will be the next fire support command and control system fielded by the 
Marine Corps. The program began as an Army project, however in 1990 the Marine 
Corps joined the program. Today, the Army is the lead service for AFATDS. 
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AFATDS will be an exponential improvement over IFSAS/TACFIRE. While all 
functional areas have been enhanced and improved, the greatest improvement is in the 
area of the user interface. Color screens, digital maps with terrain features, “windows” 
interface environment with mouse controls are just the beginnings of the improvements. 
However, many significant problems remain. AFATDS challenges include: 

1) Currently AFATDS is not interoperable with the Joint Maritime 
Command Information System (JMCIS) nor is it DII COE compliant 

2) Runs in the UNIX Operating System, while TCO is running in Windows 

3) No current support for Microsoft Office applications 

4) Unit cost $ 1 1 7,000 

5) Total weight of the system intended for use in a battalion COC is 696 
pounds (far from mobile) 

While all of these programs/systems are worthwhile and serve a need, many of 
these systems were developed without considering interoperability/network issues. Not 
all of these systems use the same operating systems, or the same hardware platforms, or 
network protocol stacks or even similar message formats. 

D. PLANNED COMMUNICATIONS ARCHITECTURE 
1. Tactical Data Network (TDN) 

The TDN is designed to augment the existing Marine Air-Ground Task Force 
(MAGTF) communications infrastructure by interconnecting gateways (down to the 
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Major Subordinate Command) and servers (down to the battalion/squadron level) to form 
the communications backbone for MAGTF tactical data systems. TDN will provide the 
functions of data transfer, IP routing, network management, and value added services 
such as directory services and message handling. The TDN system will connect via the 
existing long-haul transmission systems; switched telephone network; and single channel 
radio nets. 

As can be seen in Figure 1 1, the connectivity below the regiment level is still via 
EPLRS and SINCGARS radios which will provide a very limited throughput capability. 
Throughput is defined as the average amount of data (per second) carried by the system. 
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2 . 



Enhanced Position Location Reporting System (EPLRS) 



As depicted in Figure 4, EPLRS is designed to be the link for the MAGTF tactical 
data system architecture. EPLRS will be fielded down to the Marine Corps infantry 
company level and is intended to be the primary means of secure, real-time data 
distribution for sensor to shooter links. EPLRS is a Ultra High Frequency (UHF) radio 
operating in the 420-450 MHz range. EPLRS uses synchronous time division multiple 
access (TDMA), frequency hopping, error correction coding, and embedded encryption to 
provide a secure transmission channel. EPLRS is capable of supporting multiple 
communications channels and has automatic relay capabilities. 

One of the main characteristics that makes EPLRS a valuable asset is its 
capability to provide position/navigation information both horizontally and vertically. 
Two major drawbacks, in the view of the authors, are EPLRS limiting data throughput 
and the carrying weight. EPLRS provides two types of low data rate (LDR) needlines up 
to 14,400 bps, and three types on high data rate (HDR) needlines of between 50 - 100 
Kbps. The authors believe that this will not provide the needed throughput that data 
intensive applications of the future will demand. Additionally, each EPLRS radio weighs 
1 7 lbs or 26 lbs with batteries installed. The authors believe that this amount of weight is 
not feasible for a Marine infantryman to carry resulting in the EPLRS radio being always 
tied to a tactical vehicle. 
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3. 



Data Automated Communications Terminal (DACT) 



The DACT is a tactical battlefield situational awareness system and 
communications terminal designed for the battalion level and below. It is essentially, a 
sub-notebook sized, “rugged” computer with an internal GPS (Global Positioning System 
receiver) and an SP-TCIM for interface with current combat net radios. Today, the 
DACT comes in one variety known as the “RHC” or rugged handheld computer. To 
date, the DACT has not been fielded to operational units. Though no official decision has 
been made, it appears that future “DACTs” will come in an variety of shapes and sizes 
varying from notebook size to a palmtop sized unit to meet the variety of different users 
within a battalion organization. 

4. Near Term Digital Radio (NTDR) 

The NTDR is an Army tactical radio that is being developed for mobile 
networked IP data-only applications. It is intended for use as a backbone radio for the 
Army’s Tactical Operations Center (TOC)-to-TOC communications at the Brigade level 
and below. The NTDR is built to the same form factor as the EPLRS radio and can use 
the EPLRS installation kits. The NTDR uses two antennas, one for an embedded Global 
Positioning System (GPS) receiver and one for the UHF communications band (225-450 
MHz). 

SPA WAR Systems Center, San Diego (SSC-SD) has been tasked by the Marine 
Corps Amphibious Warfare Technology (AWT) communication program office to 
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investigate how the Joint Tactical Radio System (JTRS) can be tailored to meet the needs 
of present and future wireless networking requirements for the Marine Corps. JTRS is 
described in the next section. As a part of this task, SSC-SD is evaluating existing 
products as an interim solution. This is where the NTDR comes in. The NTDR radios 
are designed to self-organize into a dynamic two-tiered network scheme of backbone 
cluster heads and affiliated cluster members as shown in Figure 12. 




Figure 12. NTDR Network Architecture From Ref. [19]. 



Within the NTDR network, data is routed and relayed automatically between 
users and data can hop across up to seven nodes. While roaming, the cluster members are 
automatically handed off between the backbone cluster heads. In the event of a cluster 
head failure, the NTDR architecture is self-healing. The radios utilizes the Radio Open 
Shortest Path First (ROSPF) as its routing protocol which eliminates the HELLO protocol 
used by the Open Shortest Path First (OSPF) protocol found in traditional route discovery 
to reduce network overhead bandwidth. NTDR uses Carrier Sense Multiple 
Access/Collision Detection (CSMA/CD) as its radio frequency (RF) channel access 
protocol for data transmission. Additionally, to minimize multiple access interference, 
NTDR network communications is further subdivided into three frequencies: (1) control 
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channel frequency, (2) intra-cluster local frequency, and (3) inter-cluster backbone 
frequency. 

With the Marine Corps deployment strategies that cover hundreds of kilometers in 
both land and sea based operations, a networked communications architecture like the 
NTDR provides is a necessity for these types of operations. But in its current state, 
NTDR does not provide for all required capabilities the Marine Corps needs. The 
specific issues that need to be addressed are as follows: 

a) NTDR is programmed with a clear-to-send (CTS) timeout that limits its 
operating range to about 20 nmi between any two radios. This distance needs to be 
increased because Marines operate in ranges greater than 20 nmi. 

b) Each NTDR has embedded GPS capability, but this position/location 
information is not passed across the network so that situational awareness applications 
can use this data. 

c) The NTDR currently uses FORTEZZA encryption that does not meet the 
military type 1 COMSEC required for tactical communications. A FORTEZZA 
encryption card is about the size of a thick credit card and when it is inserted into a 
workstation it is used for user authentication and access rights of the individual. 

d) NTDR has a restricted IP addressing scheme which does not allow the 
radio’s IP address to be changed to a user’s subnet address. Therefore, in order to 
interoperate with other IP equipment, the radio must be connected to a user’s subnet 
through a router. Currently, this is not always possible. 
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e) The NTDR does not support multicasting. Multicasting provides an 
efficient way of disseminating data from a sender to a group of receivers which enables 
more efficient bandwidth utilization on the network [Ref. 19]. 

5. Joint Tactical Radio System (JTRS) 



The JTRS, while still in the concept phase, is being designed to be a multi- 
band/multi-mode digital radio that will work in all environment domains. The JTRS 
family of radios will be an open systems architecture that will interoperate with legacy 
systems while being capable of future technology insertion. The JTRS is being designed 
so that users needing multiple paths for voice and/or data will be served by JTRs that are 
capable of simultaneously operating on multiple frequency bands and modes across 
multiple networks. The JTRS will automatically route data within and between different 
networks. Some of the projected characteristics are as follows: 

a) Plug and play versatility 

b) Field-configurable modular hardware 

c) Field-programmable waveform software 

d) Embedded position location with automatic situation awareness feed to the 
network 

e) Secure data network 

f) Three or more other networks/modes 

g) Automatic local and internet routing 
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h) Dynamic networking, addressing, and bandwidth allocation 

i) Operates on-the-move 

A wide-band capable JTR is planned to be available for fielding during Fiscal 
Years (FY) 2000-2004, and a multi-band multi-mode capable JTR is planned to be 
available from FY 2004-2010 [Ref. 20], 

E. THE FUTURE COURSE 

A new framework must be considered for our tactical software/hardware and 
tactical networks. The goal should be that our tactical systems are equal to our garrison 
systems. Whenever feasible, service members should not have to learn a new operating 
system just for tactical systems. Further, stove-pipe style systems can not be allowed to 
exist. Stove-piped systems are systems that were developed to support a functional area, 
but in many instances, these systems would not interoperate with each other allowing for 
the passing of time and mission critical data. Example stove-piped systems for a typical 
COC are depicted in Figure 13. WWMCCS was the World Wide Military Command and 
Control System, which has been replaced by GCCS. TBMCS is the Theater Battle 
Management Core System, which is an upgrade to the Contingency Theater Automated 
Planning System (CTAPS). TBMCS is used to create the Air Tasking Order (ATO). 
ATLASS is the Asset Tracking Logistics and Supply System. Finally, an end user 
terminal (i.e., a computer) must be capable of running multiple applications. IT-21 
principles state that we should drive everything into a single PC and that the operating 
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system will be some flavor of the Windows OS. The TCO program has started the 
Marine Corps down this path. 



C4I Stovepipe Software 







Figure 13. C4I Stovepipe Software. 

The command and control software application for the TCO program is C2PC. 
Running on a commercial laptop provides a hardware environment which is familiar and 
allows for many other applications such as the Microsoft Office suite and additionally 
provides for email capabilities. Future tactical software applications, which require 
mapping and overlay functions, should be designed to “ride on top” of C2PC. Figure 14 
is a proposed future architecture for tactical software. 

In this proposed model, a Complete Instruction Set Computing (CISC) operating 
system, such as Windows NT, will be the standard OS for all tactical applications. At the 
very least, any tactical application should be Windows based. If the software application 
requires mapping information or a common tactical picture (CTP), then the application 
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should use C2PC as the base application and “ride on top” of C2PC. The CTP is the 
hostile, neutral, and friendly forces current, anticipated, projected, and planned 
disposition including amplifying data, for a single operation. 

The Defense Information Infrastructure Common Operating Environment (DII 
COE) is a collection of building blocks which form a software backplane. The DII COE 
is a layered software architecture consisting of three layers. The layers are: the kernel, 
the infrastructure services, and common support applications. The common support 
application level provides for a common data understanding or information exchange 
interoperability. This level brings the capabilities for processing and displaying common 
data formats. 



Proposed C4I Software Architecture 



Application 



Interface 

Architecture 

Standard 



C2PC 


INTEL 

Client 


Fire 

Support 

Client 


LOG 

Client 


Office 

Automation 

Package 


Application Program Interface 


CISC Operatin 


g System 






sS T\ • - 



C 

O 

E 



Figure 14. Proposed C4I Software Architecture. 
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IV. FSPS APPROACH AND IMPLEMENTATION 



A. INTRODUCTION 

Prior to discussing the FSPS developmental concept, it is important to look at the 
Marine Corps fire support process concepts and philosophies to get an understanding of 
the information flow between the different units. Once this is done, we will look at FSPS 
and how the program can assist the users of the program in the execution of fire support 
planning. 

B. FIRE SUPPORT PLANNING 

Fire support functions can be divided into two distinct classes: fire support 

planning and fire support execution. Fire support planning encompasses tasks associated 
with planning for the potential use of fire support assets (artillery, mortars, naval surface 
fire support, and aircraft delivered ordnance). Fire support planning tasks for Marine 
Corps units at the regiment level and below include developing a fire support plan, an 
execution matrix, an attack guidance matrix, a target list, and a list of fire support 
coordination measures. Fire support planning involves the “what,” “where,” and “when” 
of indirect fires in a future engagement and is an integral part of creating a combat 
operations order. Fire support execution, on the other hand, involves requesting assets to 
fire on a particular target identified on the current battlefield. Fire support execution is 
not covered in this thesis. 
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1 . 



Fire Support Planning Cycle 



Like all combat operations planning, fire support planning is a continuous, 
interactive and changing process. The planning process involves nearly every echelon in 
the warfighting chain of command and demonstrates flexibility by allowing low-level 
input with high-level refinement and high-level fire support plan production. The output 
of the fire support planning process is a fire support plan which is included as part of a 
combat operations order. 

a. Personnel in Fire Support Planning Cycle (Marine Regiment & 

Below) 

Listed below are the primary personnel involved in preparing and 
providing input for the fire support plan. 

* Regimental Fire Support Coordinator 

* Battalion Fire Support Coordinator and Artillery Liaison Officer 

* Company Commander and Artillery Forward Observer 

b. Fire Support Planning Documents 

The following are the primary fire support planning documents: 

* List of Targets (recommended targets) 

* Target List (approved targets) 

* Fire Support Plan 

* Attack Guidance Matrix (AGM) 
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* Execution Matrix 

* Fire Support Coordination Measures (FSCMs) 



c. Fire Support Planning Cycle Diagram 



In Figure 15 below, the fire support planning cycle is depicted including 



the units and personnel involved, and the actual information that is passed. The fire 



support planning cycle typically begins at the Company Commander/FO level. 









Figure 15. The Fire Support Planning Cycle. 



59 



c. 



THE FIRE SUPPORT PLANNING SYSTEM (FSPS) CONCEPT 



1. Background 

The fundamental objective of C4I systems is to get the critical and relevant 
information to the right place at the right time [Ref. 23]. Moreover, automated systems, 
particularly C2 systems, should be relevant, technologically current, and most 
importantly, user-friendly. To provide systems that are technologically relevant is a 
tremendous challenge for both the military and civilian sector. The civilian sector is fast 
discovering that 4 th generation language COTS software development tools provide a 
viable and economically feasible means to achieve such ends. 

Two recently been published documents describe a direction and vision for future 
DoD C2 systems. These are the “C4I for the Warrior” paper and the Information 
Technology for the 21 st Century (IT-21) initiatives originated by Admiral Clemins. 
Though not explicitly stated, these documents provide tacit support for Win32 compliant 
software applications such as C2PC. They also indirectly provide a foundation for the 
“Fire Support Planning System” concept. The warrior of the future “needs a fused, real- 
time true picture of the battlespace and the ability to order, respond and coordinate 
vertically and horizontally to the degree necessary to prosecute the mission in that 
battlespace” [Ref. 24], Today our C2 systems, specifically GCCS, do not provide a 
readily available common operating picture for all warfighters at all echelons in real-time. 
While the GCCS system is extremely capable, the fact remains that it is only accessible to 
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warfighters on medium to high level staffs, i.e., those with GCCS access. The grunts on 
the “pointy end of the spear” simply do not yet enjoy the same picture or battlespace 
awareness. 

IT-21 introduces concepts which depart from past DoD computer philosophies 
and supports the C2PC concept. IT-21, among other things, calls for a serious attempt to 
drive everything to a single PC, to use commercial-off-the-shelf products whenever 
feasible for both hardware and software, and ultimately to have our garrison computer 
systems equal to our tactical computer systems [Ref. 25]. Stated another way, a service 
member should be using the same operating system and user interface whether behind a 
desk in garrison or in a foxhole. An ultimate goal would be for service members to use 
not only the same operating system but also the same mobile computer (hardened laptop) 
both in garrison and in the field. 

2. The Concept 

Believing that tactical computers can and should be on a similar hardware 
platform and the same operating system as garrison computers, we sought to develop a 
fire support system which would address these requirements. The initial idea was to 
develop a fire support system which could run on the Windows operating system (OS), 
and present the user with a program with the “look and feel” of other familiar windows 
applications. Additionally, the fire support system needed to use C2PC as the mapping 
and overlay engine. 
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D. MCTSSA PROJECT REQUIREMENTS 



The Marine Corps Tactical Systems Support Activity (MCTSSA) provided the 
framework for the development of the Fire Support Planning System. MCTSSA’s 
guidance was to “write (code) a fire support module for their existing Win32 command 
and control program (C2PC) that would manage target lists, targeting overlays, and target 
planning. Win32 is Microsoft’s Windows 32-bit architecture. MCTSSA essentially 
wants to port as much functionality as possible from the Unix AFATDS system to Win32 
using C2PC as the mapping, database, and overlay engine” [Ref. 26], 

1. Project Refinement 

Using this broad framework provided by MCTSSA, we sought more detailed 
specifications from the fire support community at Fort Sill, OK. Below are the Marine 
Corps Artillery Detachment’s (located at the US Army’s Artillery School in Ft. Sill) 
recommended functional areas for a Windows based fire support system: 

a) Artillery Fire Mission Processing. 

b) Mortar Fire Mission Processing. 

c) Naval Surface Fire Support Fire Mission Processing. 

d) Battlespace Geometry Management. 

e) Artillery Target Intelligence Interface. 

f) Survey Interface Requirements. 

g) DASC Interface Requirements. 
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h) Electronic Warfare functions. 

i) Communications functions. 

j) Fire Support Planning utilizing Ground, Air and Naval assets. 

Each of the above functional areas fit into either the fire support execution or fire 
support planning category. With the intention of designing a fire support planning 
system, only items (d), (e) and (j) were considered for inclusion in our system. 

a. Battlespace Geometry Management: 

The system must have the ability to send, receive, and, if authorized, 
adjust the following coordination measures: 

* All Fire Support Coordination Requirements. 

* All Maneuver Control Measures. 

* All unit boundaries, to include Fire Support Stations and Fire Support 

Areas as required for Naval Surface Fire Support platforms. 

* All obstacle plans. 

* All Target Reference Points. 

b. Artillery Target Intelligence Interface 

The system must be able to create, send, and receive the following types of 
artillery target intelligence: 

* High Payoff Target List. 
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* High Value Targets. 

* High Payoff Targets. 

* Attack Guidance Matrix. 

* Target Selection Standards. 

c. Fire Support Planning Utilizing Ground, Air, and Naval Assets 

The system must be capable of: 

* Deliberate fire support planning. 

* Storing/transmitting fire plans. 

* Obtaining and submitting target nominations to higher headquarters (HHQ). 

* Producing: Target list worksheets, target overlay equivalents, fire support 
execution matrix equivalents, and target bulletins. 

E. FSPS DEVELOPMENT ENVIRONMENT 

The Fire Support Planning System was developed using COTS/GOTS 
technologies. For the software development, Microsoft’s Visual Basic 6.0 was used with 
Microsoft’s Access 97 as the database engine. Microsoft’s HTML Help Workshop 
application was used to build all help files. Additionally, one C2PC Active X component 
(PosSelectBtn.ocx) was used to capture and import grid coordinates from a digital C2PC 
map into the FSPS application. 
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The RAD methodology of software development was an essential element in the 
creation of FSPS. Within eight months, we were able to go from a concept and user 
requirements to a functional (although still not perfect) application. This eight months 
also included time to learn the Visual Basic language and Integrated Development 
Environment (IDE). The lesson learned from our research in this area is that RAD and 
COTS applications provide a viable alternative to the traditional DoD software 
development practices. RAD and COTS development tools allowed us to create an 
“80%” solution today. Clearly, this meets end user needs better than the perfect solution 
in four or five years. 

1. Assumptions 

The following assumptions were made concerning the future operating 
environment in which FSPS would reside: 

* Email or FTP services would be available to allow for file transfer. 

* An approved “windows laptop” would be available. 

* A communications network would exist. 

F. FSPS APPLICATION FRAMEWORK 

Conceptually, our model identifies three levels in the fire support chain of 
command; the forward observer (FO) at the company level, the artillery liaison 
officer/battalion fire support coordinator (LNO/FSC) at the battalion level, and the FSC at 
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the regimental level. The FSPS application is designed to address fire support 
requirements (as previously delineated) at each of these echelons. In FSPS, these three 
echelons are displayed as “profiles.” The first input screen a user encounters requests that 
a profile type be chosen as seen in Figure 1 6. 




Figure 16. The User Profile Selection Screen. 

The functionality associated with each profile varies slightly based on the user’s 
chosen profile. For instance, only the FSC has the capability to publish the final Target 
List. FOs and LNOs can input recommendations but cannot publish the approved Target 
List. Based on the user’s profile selection, one of the following screens in Figure 17 is 
displayed. 
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Figure 17. FSPS Profiles. 



FSPS Initialization 



Prior to using the FSPS application, a few items must initially be input from the 
FSC. These items are operation names or phases and unit specific information. These 
input selections are accessible from the FSC Options screen under “Initialize Operation 
Names” and “Initialize Unit Information.” A picture of each if presented in Figure 18. 
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Figure 18. Initialization of Operation and Unit Names. 

These two options give the senior fire support coordinator the ability to ensure 
naming convention consistency for both unit and operation/phase names. Since the FSC 
will ultimately receive target nominations for a particular operation or operation phase 
from his subordinates, it is convenient to establish standard names for both the 
subordinate units and the particular operations to alleviate potential confusion. 



68 





The fire support coordinator also has the responsibility of assigning blocks of 
target numbers to his subordinates. In FSPS, this function can be accomplished via the 
“Initialize Unit Information” screen. The FSC simply assigns the target block’s letter 
designator and starting and ending numbers to a particular unit. When the FO initializes 
his FSPS application via the FO Setup Wizard, his entire block of target numbers is 
automatically generated. 

2. Target Nominations 

Perhaps the most important portion of the fire support planning process is the 
creation, receipt, validation, and consolidation of targets. Target nominations typically 
begin at the lower levels and are passed up the chain of command. Once nominations are 
reviewed, they are either deleted or approved for inclusion in the Target List. This 
process is conducted at each echelon (see Figure 15). Ultimately, the senior fire support 
Marine creates one “master” list, the Target List, which is disseminated back down the 
chain of command. 

In FSPS, targets are created via the “Target Editor” screen. This screen, presented 
in Figure 19, is available to all three profiles with only slight differences in functionality. 
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Figure 19. Target Editor. 

The screen opens with the “Min Tgt Information” tab in view. The input boxes 
under the “Min Tgt Information” tab are typically the only required information for a 
target nomination. The user adds a target by clicking the “Add Tgt” button provided on 
the lower left hand comer of the Target Editor screen. Once all target information has 
been entered, the user selects “Ok.” The targets may also be deleted via the “Delete Tgt” 
button or may be changed by clicking on the “Edit Tgt” button. 

If desired, or required, the user can input other target related information by 
clicking on the “Tgt Details” tab. Additionally, in the right pane, a listing of previously 
input target numbers, descriptions, and locations is provided to give the user a quick 
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snap-shot of all input targets. Should the user desire to view the targets and all of their 
associated details, the user can click “List of Targets” under the “View” menu available 



in the main menu bar. When clicked, the screen presented in Figure 20 is made available. 
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Figure 20. List of Targets. 



Once the user has input all desired targets, they may be saved by clicking the 
“save” icon or selecting “save” from the main menu bar. Once saved as a .fsp file, the 
target nominations may be forwarded up the chain of command for additional processing, 
or for viewing at a later time be the user. 

The only differences between the target editor screen for FO’s versus LNO’s and 
FSC’s is the ability to run the target consolidation screen and the ability to create the final 
target list. LNO’s and FSC’s may both run the target consolidation function but the 
target list can only be produced via the FSC’s target editor screen. 



71 





The target consolidation function allows LNO’s and FSC’s to quickly ascertain if 
target duplications exist in terms of location. If two or more targets have the same grid 
location or if they are within a given distance (in meters, as determined by the LNO/FSC) 
from each other, the LNO or FSC may choose to delete or “consolidate” specific 
nominations. Figure 21 shows the target consolidation screen. 




Figure 2 1 . Target Consolidation. 



Once the FSC has received all target nominations and conducts his own 
consolidation, the FSC may create the target list by selecting “Add current LOT to Target 
List” from the main menu bar. After the target list has been created, it is saved and 
disseminated down the chain of command. Once received and imported, LNOs and FOs 
may then view the approved target list. An example target list screen is shown in Figure 
22. Within the target list screen, users also have the option to view all targets or they 
may to view targets based on a given operation name. 
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Figure 22. Target List. 



3. Target Groups and Series 

A target group is defined as more than one target fired simultaneously, while a 
target series is more than one target fired in accordance with a time schedule. Target 
groups and series are typically created during the target generation process. For example, 
after a FO selects a number of targets for nomination, he often will create a number of 
target groups and series as well. Accordingly, in FSPS, these two targeting options are 
accessed via the Target Editor screen. FSPS addresses these aspects of the targeting 
process via the screens presented in Figures 23 and 24. 
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Figure 23. Groups. 




Figure 24. Series. 



4. Fire Support Plan 

The fire support plan is produced by the FSC. The plan includes a written portion 
and three attachments. These attachments are the fire support coordination measures 
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(FSCMs), an execution matrix, and an attack guidance matrix (AGM). In FSPS, only 
LNOs and FSCs may create or edit any fire support plan document. FOs are restricted to 
viewing these documents. 

The first screen available through the “fire support plan” option on either the 
LNO’s or FSC’s Options screen is presented in Figure 25. Within the “fire support plan” 
screen are three text boxes for the FSC to write the Commander’s Intent, Coordinating 
Instructions, and Critical Information portions of the fire support plan. Additionally, this 
screen has three buttons to access the fire support plan attachments. 




Figure 25. Fire Support Plan. 

The AGM, presented in Figure 26, is a replication of the current AGM used by the 
1 st Marine Division (1 st MarDiv). This format is not currently part of the Marine Corps’ 
fire support doctrine, but has been used by the 1 st Marine Division for the last five years 
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and is currently being considered for inclusion in the Marine Corps fire support doctrinal 
publications. 




Figure 26. 
The execution matrix and 
presented in Figures 27 and 28. 



Attack Guidance Matrix. 

fire support coordination measures screens are 
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Figure 27. Execution Matrix. 




Figure 28. Fire Support Coordination Measures. 



5. File Saving and Dissemination 



Once all pertinent information has been input, the user saves the information by 
clicking the “save” icon or by selecting “save” from the “file” menu option on each 
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screen. The information is saved with the “.fsp” file extension and is saved as a tab 
delimited ASCII (American Standard Code for Information Interchange) file. These files 
may now be exported up or down the chain of command and input into the users FSPS 
application. The files may be delivered via a 1 14” floppy disk, FTP (file transfer 
protocol), or as an email attachment. 

6. Wireless Implementation 

Once the FSPS files have been saved, they need to be disseminated either up or 
down the chain of command to the designated recipient. It is the authors belief that this 
dissemination should take place over a wireless tactical network vice the combat net radio 
network currently in place. In Chapter V, a comparison of the data transfer rates and 
throughput between the two technologies will be examined. 
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V. 



ANALYSIS AND FINDINGS 



The current software development and communications architecture does not 
work in this data intensive age. Software development is too slow, and the 
communications equipment does not provide the necessary bandwidth required. With 
that, we set out to evaluate the FSPS and wireless technologies in the tactical arena with 
the aid of 1 1 th Marines and MCTSSA. 

Our analysis and evaluation was divided into two areas: a limited usability study 
of the FSPS application and a more technical evaluation of file transfer over both tactical 
radios and wireless equipment. 

A. USABILITY STUDY 

1. Why Complete a Usability Study? 

One of the most important aspects of the RAD method of developing software is 
user feedback. For a software application to be really useful, end user input must be 
garnered throughout the development process. One advantage we had in creating FSPS 
was that one of the developers was an artillery officer and therefore had personal 
experience and technical knowledge regarding many of the user requirements. However, 
feedback from one individual is not enough. We therefore sought responses from other 
Marine artillerymen concerning the design, “feel,” and functionality of FSPS. 
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2 . 



The Study 



Because the main focus of our research was on the development of the FSPS 
application and the exploration of wireless technologies, we did not have sufficient time 
or resources to conduct a formal evaluation of the FSPS application. Instead, we chose to 
conduct an informal usability study which is actually more appropriate for this stage of 
the development process [Ref. 28]. 

a. The Participants 

The participants were all Marine artillerymen currently serving in the 1 st 
Marine Division at Camp Pendleton, California. The four participants were volunteers 
and had a wide variety of fire support experience. 

b. Participant Demographics 

* Major, 12 years of service, currently serving as a Marine Regiment Fire 
Support Coordinator. 

* 1 st Lieutenant, 3 years of service, currently serving as an infantry battalion 
artillery liaison officer. 

* 1 st Lieutenant, 3 years of service, currently serving as a forward observer. 

* Sergeant, 8 years of service, currently serving as an artillery liaison chief for 
an infantry battalion. 

c. Procedures 

All participants were gathered into a room and received an hour-long 
presentation on the use of the FSPS application. Following the presentation, the users 
were each given a task list and asked to perform various fire planning operations. Data 
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was collected on each task completed by each participant. Following this, each 
participant was asked to complete a user feedback form. 

d. Task List/Feedback Form 



For this usability study, tasks were created for Forward Observers and Fire 
Support Coordinators. Since the Liaison Officer’s (LNO) job incorporates portions of 
both the FO and FSC tasks, this particular job was not part of the study. Following the 
completion of the task list, each participant was asked to complete a user feedback form. 
The task lists and user feedback forms can be found in Appendix A. 

3. Presentation of data 



Below is a compilation of all data obtained from the questions on the user 
feedback form. 

1 . The concept of a Windows based fire support planning tool is? 

Outstanding Excellent Average Poor Unacceptable 




Figure 29. Question 1 . 
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2. As a possible solution, the Fire Support Planning System application is? 
Outstanding Excellent Average Poor Unacceptable 




Figure 30. Question 2. 



3. What features of the Fire Support Planning System did you like? 

* Continuous update of all units and forward observers (when connected to a 
TDBM via C2PC). 

* Windows based system with point and click functionality. 

* Interface/compatibility with TCO. 

* Easy initialization. 

* Fire planning is quicker from the FO to the LNO and FSC. 

* Equipment for FOs, LNOs, and FSC is much smaller than current 
computers (assuming COTS notebooks/laptops are used). 

* Simple, very easy to use. Eliminates the large number of hours an operator 
would have to spend learning the program. 

* Provides the ability to edit and review input. 

* Able to pass information rapidly. 

4. What features of the Fire Support Planning System did you dislike? 

* Menu bar icons and menu text are not on the same window/screen. 
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5. Compared to the automated fire support planning tools you currently use, the 
Fire Support Planning System is? 



Superior Better The Same As Worse Than Much Worse Than 




6. Does the Fire Support Planning System application provide all the 
functionality you need to perform your mission? 

Yes No If no, then what else do you need? 

* Not compatible with the BCS (computer which computes technical firing 
solutions). 

* Target information symbology is not placed on the map in C2PC. 

* Bugs in some of the forms. 

* Needs to allow for sending a fire mission. 

* Series screen needs to be displayed in a “worksheet” format. 

4. Interpretation of Data 

Because this study was a small, informal, and relatively unsophisticated usability 
study, no “scientific” results can be realistically derived. However, a number of useful 
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generalities can be inferred. First, the results of questions 1, 2, 3, and 5 from the user 
feedback form show that potential users desire a Windows based fire support tool and that 
the FSPS application prototype is certainly a possible starting point worthy of continued 
development. Second, question 4 and general observations made by the authors 
highlighted problem areas with FSPS. 

5. Discussion 

Based on the results of the usability study and the authors’ knowledge of FSPS, a 
number of recommendations are suggested below to address deficiencies in the current 
version of the application. The recommendations are broken down into two categories: 
current version recommended changes/fixes and future functionality requirements. 

a. FSPS Version 1.0.0 Recommended Changes/Fixes 

1) Screen Resolution Independence. In its current state, all FSPS 
windows have a preset size. There is no functionality for users to resize the screens. 
Users may only minimize screens. FSPS windows display acceptably with a monitor 
screen resolution of 800 x 600 or greater. A screen resolution of at least 800 x 600 works 
well with a monitor screen size of at least 12 inches. With a screen size smaller than 12 
inches, all FSPS windows automatically receive horizontal and vertical scroll bars. 
While this “works,” it is not optimal for users with small screen computers such as the 
DACT. For improved readability, it is recommended that all screens within FSPS be 
coded to automatically resize based on the users particular screen resolution. 
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2) Menu-Bar Icons. In its current state, there is a disconnect 
between the parent form menu bar functions and the child form menu bar icons. All 
menu bar text information resides on the main “container” form while menu bar icons 
reside on the child forms. This is not an optimal solution and is not in keeping with 
current “windows conventions.” All child form menu icons must be moved so that 
they reside on the parent form’s menu bar. 

3) Target Editor Consolidation Screen. This screen allows the 
FSC to search the current list of targets to determine whether or not two or more 
target nominations are within a given distance from one another (see chapter IV). The 
current algorithm has a shortcoming in that it displays duplicate values. In other 
words, if targets A and B are within 1 000 meters of each other than the output display 
shows both A and B in addition to B and A. Further, the algorithm is calculated 
based on x and y coordinates when the search for duplicates should more accurately 
be based on a radius. 

4) Series Editor Screen. The FSPS Series Editor currently 
displays all series related information in text boxes (see Figure 23). Created 
manually, a series worksheet looks much more like a spreadsheet. Figure 32 shows a 
blank “Scheduling Worksheet” used to plan a series. It is recommended that the 
current Series Editor be replaced with a spreadsheet style editor. 
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Figure 32. Scheduling Worksheet. 

5) Fire Support Coordination Measures Screen. The Fire Support 
Coordination Measures screen provides an ability for those using the FSC Profile to 
input a variety of FSCMs. While the functionality of this screen “works” it is a poor 
means for a FSC to input these measures. FSCM’s are most typically displayed as a 
map overlay. The C2PC application already has a map overlay creation capability. 
The C2PC overlay creation tool is the option a FSC should use to create all FSCMs. 
It is recommended that the FSCM functionality within FSPS be eliminated. 

6) Help Files. In its current state, the help files are essentially 
incomplete. The framework has been established to create help files using 
Microsoft’s HTML Help Workshop application, however, the content is currently 
lacking. 
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b. Future FSPS Functionality 



1) Transfer of FSPS Files. FSPS Version 1.0.0 requires that files 
be transferred either as email attachments or via FTP. This implies that an email or 
FTP server must be made available on the network. Additionally, this adds more 
tasks for the user, i.e. that user must save the files locally, and then open an email or 
FTP application to send files. This is not the optimal solution. Ideally, some transfer 
capability should be integrated into the FSPS application. Users should only have to 
push a “transfer” button from within FSPS, add the recipient’s address and send the 
files. 

2) Target Overlay Creation. FSPS imports map coordinates from 
C2PC. This feature is an integral part of the target editing screens. However, to be 
truly useful for target planning purposes, after importing a grid coordinate FSPS 
should place a target symbol (a cross for point targets) and the related target number 
onto the map resident in C2PC. Additionally, when users import their target list after 
receipt from the FSC, FSPS should have the ability to place all the targets onto the 
C2PC map. 

3) Interoperability with AFATDS and BCS. To actually 
implement the FSPS application in the Fleet Marine Force, it must have the ability to 
exchange information with both AFATDS and BCS. AFATDS has a robust database 
that would be useful to the Marine Corps at the division level and higher even if FSPS 
were deployed at the regiment and below. Additionally, the U.S. Army already uses 
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AFATDS thereby creating a requirement for the Marine Corps to have an 
interoperability capability to enable joint warfighting. Moreover, FSPS must have an 
ability to send targeting information to the BCS system which computes technical 
firing solutions for artillery pieces. 

4) PosSelectBtn.ocx. This is an Active X component which is 
part of the C2PC application. The component extracts map coordinate information 
from a map resident in C2PC and imports it into a text box. Though obtaining the 
grid coordinate is important, of equal importance for computing a technical firing 
solution is altitude information. It is recommended that MCTSSA add an Active X 
component which extracts both the grid coordinate and its associated altitude. 

B. FILE TRANSFER ANALYSIS 

In an attempt to demonstrate the differences between the data transfer rates and 
throughput of the current combat net radio (CNR) and commercial wireless technologies, 
two networks were installed with the assistance of Marines at MCTSSA. The first 
network utilized the SINCGARS radio and the SP-TCIM, and the other utilized Proxim’s 
RangeLAN2 wireless ethemet card. Both networks utilized a Panasonic CF-27 hardened 
laptop computer as the end-user terminal. Microsoft’s NetMeeting software was used as 
the file transfer program. 
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A comparison of the time to transmit a 91,364 byte C2PC overlay file via wireless 
equipment with a maximum data rate of 2Mbps is shown in Figure 33 and the time to 
transmit the same file via SINCGARS/TCIM with a maximum data rate of 16,000 bps is 
shown in Figure 34. 
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Figure 34. Time to Transmit a 91,364 Byte C2PC Overlay File Via SINCGARS/TCIM. 



Additionally, a comparison of the time to transmit a much smaller 6,192 byte 
FSPS overlay file via wireless equipment with a maximum data rate of 2Mbps is shown 
in Figure 35 and the time to transmit the same file via SINCGARS/TCIM with a 



maximum data rate of 16,000 bps is shown in Figure 36. 
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Figure 35. Time to Transmit 6,192 Byte C2PC Overlay File Via Wireless LAN. 




Figure 36. Time to Transmit 6,192 Byte C2PC Overlay File Via SINCGARS/TCIM. 

In addition to analyzing the time to transmit a file, we also looked at the 
throughput, in bits-per-second (bps), of each of the files. A comparison of the throughput 
of the 91,364 byte C2PC overlay file via wireless equipment with a maximum data rate of 
2Mbps is shown in Figure 37 and the throughput of the same file via SINCGARS/TCIM 
with a maximum data rate of 16,000 bps is shown in Figure 38. 
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Figure 37. Throughput of a 91,364 Byte C2PC Overlay File Via Wireless LAN. 
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Figure 38. Throughput of a 91,364 Byte C2PC Overlay File Via SINCGARS/TCIM. 
Additionally, a comparison of the throughput of the 6,192 byte C2PC overlay file 
via wireless equipment with a maximum data rate of 2Mbps is shown in Figure 39 and 
the throughput of the same file via SINCGARS/TCIM with a maximum data rate of 
16000 bps is shown in Figure 40. 
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Figure 39. Throughput of a 6,192 Byte C2PC Overlay File Via Wireless LAN. 
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Figure 40. Throughput of a 6,192 Byte C2PC Overlay File Via SINCGARS/TCIM. 



As can be seen from Figures 33-40 above, the 6,192 byte file was transmitted over 



19 times faster, and the 91,364 byte file was transmitted over 50 times faster via the 



wireless network than the CNR network. Throughput was also increased utilizing the 
wireless equipment with an increased throughput of 27,840 bps for the 6,192 byte file and 
148,180 bps for the 91,364 byte file. Although only two files were transmitted, we found 



the proof-of-concept results very impressive. 
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VI. CONCLUSIONS AND RECOMMENDATIONS 



A. CONCLUSIONS 

The objective of this thesis was to demonstrate that wireless COTS technologies 
and COTS software development tools can be used to quickly enhance the ability of 
today’s warfighters to accomplish their mission and should become the accepted practice 
within the DoD, when feasible, other than exception. Specifically, this thesis has 
discussed the motivation for and the development of a potential fire support planning 
system which could be incorporated to work in conjunction with the Marine Corps’ 
current command and control software application C2PC. Additionally, this thesis 
discussed and analyzed current communications shortfalls and offered potential wireless 
solutions. Perhaps most importantly though, this thesis proposed a future methodology 
for developing the majority of our tactical software. 

B. ANSWERS TO RESEARCH QUESTIONS 

1. Can a Commercial Off The Shelf (COTS) wireless technology architecture 
be implemented to increase the bandwidth to allow timely passing of data 
intensive information at the Marine regiment level and below? 

The area of wireless networking is growing exponentially in the world today. 

Many advances have taken place in recent years that makes the use of wireless 

technologies within the Marine Corps very attractive, but based on the results from the 
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research conducted during this thesis, much more research must be done to make it a true 
viable alternative to the current combat radio network. 

2. Can COTS software developmental tools be used to produce software 

applications to aid the warfighter? 

As discussed in Chapter II, the RAD methodology is designed to take advantage 
of off-the-shelf software development tools. Using the RAD methodology, Microsoft’s 
Visual Basic 6.0 and Microsoft’s Access 97, we were able to build the FSPS application 
in six months. Based on the positive feedback from Marine artillerymen currently 
serving in the Fleet Marine Force regarding FSPS (see Chapter V), the authors believe 
that COTS development tools and the RAD methodology of software development are 
not only a viable means of producing timely, relevant software applications, but should 
become the standard practice for the DoD. 

C. RECOMMENDATIONS 

If the Marine Corps embraces C2PC as our tactical windows based command and 
control software application, then clearly we should strive to add greater mission area 
functionality to this baseline application. Our FSPS application demonstrates that the 
RAD methodology combined with COTS development tools are a viable means of 
meeting the needs of Marines in a timely fashion. 

While there are many individuals in academia working on different areas such as 
battery life, energy proficient protocols, and network routing to improve the capabilities 
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of wireless networks, we believe that more emphasis should be placed within the Marine 
Corps to bring these issues to the standard setting bodies and commercial vendors to 
make our unique requirements known. While MCTSSA and MCWL are testing many of 
the commercial vendor’s products on their own accord, we believe an organization should 
be designated to take the lead, and be funded, to further the research this area. 
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